Previous Page TOC Next Page



- 23 -
Security Issues


Network security is a major thorn in most network administrators' sides. Even a small network requires some level of planning, and many managers fail to see the value of implementing the type of security they really need. Of course, I've seen the opposite side of the coin as well. Some administrators wrap the people who use the network in a tight cocoon of regulations and passwords. The choke hold these people create inhibits any kind of creative resource management and often impedes work as well.

It's difficult to create a bulletproof network setup that offers the level of flexibility most users require. Adding a bit of flexibility normally means that you also open a security hole. I find that a network administrator must reach an important balance. The first thing you need to realize is that there's no such thing as a bulletproof security system. Any security system you design can be breached by someone else.

So what do you do? Just leave the network open to whoever might want to access it? That's not the way to go either. The real goal is to put reasonable security restraints in place. You need to assess your security risks and do whatever it takes to reduce your risk to an acceptable level.

More important than physical security and password protection is the cooperation of those around you. I recently went into a client's office to check on their network setup. They allowed me to use one of the employees' desks to get the work done. Right in front of me was one of those yellow reminder pads. It contained not only the employee's password, but the superior's password as well. Names were all over the desk. Anyone could have simply walked into the office and gained access to the network because of this security breach.

This incident reminded me of the importance of the "human" factor in any security plan. To really implement a good security system, you need to consider the following elements:

This might seem like a lot of work to implement security, but it isn't when you consider the loss that a single security breach can cause. A pirate isn't going to steal last week's letter to the general public; he's going to steal something valuable. The more secret something is, the better the pirate likes it. Just think about what a competitor could do with your new marketing plan or the design for that new widget you plan to produce. Even if a pirate doesn't take anything, he could leave something behind. What would a virus do to your network? It doesn't take too much thought to imagine your entire setup crumbling as a virus infects it.

The next section of this chapter addresses network security in the broad scheme of things. In other words, it actually goes a little beyond what you would need to implement in Windows NT itself. The reason I'm including it is because security needs to be cohesive. You can't create little security groups on a network. The entire network must use a consolidated plan to ensure that your security net is consistent and that there aren't any holes in it. Anything less is an open invitation to whoever would like to circumvent your security to gain access to sensitive information.

After we get past these general guidelines, I'll show you the features Windows NT provides to help you implement a company-wide plan. We've looked at many of these features already, so I won't go into a lot of detail in some areas. (I'll tell you where the detailed information does appear in this book, though.) Even if you're running a small network, you'll want to read both sections. The first section tells you what to implement and the second tells you how to do it.

I'm also going to introduce you to a lot of theoretical areas of Windows NT security. There's a lot going on under the surface in the way of security, and it helps to know a little about it. I'm not going to go into bits and bytes—that's the realm of programmers. What I do want to tell you about is the process Windows NT goes through to make your system secure. You could probably skip this section if it becomes too technical for you, but try to read as much as possible so that you have a complete understanding of how Windows NT works.

Creating a Security Plan


To run a network efficiently, you need to have a plan. Ad hoc solutions to any problem are simply that—ad hoc. They won't go very far in helping you plug a security leak or telling someone why he needs to observe a particular rule. Without a plan, you won't know what your security goals are or what steps you need to take to meet them. The problem that most administrators face is that they really aren't sure what goals a security plan helps them achieve. Figuring out what a security plan does for you is almost as important as creating it.

A security plan will help you achieve at least five goals:

  1. A security plan helps you define and organize your security system into manageable pieces. Divide and conquer is the technique used by many generals to win a war. Instead of trying to fight an entire army of problems by working on them all at the same time, take them on one at a time. You can win the war against security leaks by using this tried-and-true strategy. A network security plan is the map you need to see where to break the problem into smaller pieces.

  2. Most networks have security problems from time to time. An old employee leaves and a new one takes his place, creating a potential gap in your security net. Someone gets promoted and you need to extend his rights on the network. Will he know how to handle these new responsibilities if you don't train him? What if someone gets transferred from one department to another? Do you really want him to have access to both departments' data? The network administrator might not even know that these problems exist. What if a manager inadvertently gives someone rights to a sensitive directory? One way to find problem areas quickly is to compare the current network state with a baseline condition. A network security plan can provide that baseline. It captures the network's ideal state rather than its current state.

  3. If you're like most administrators, users constantly ask why you implement one procedure over another. They might want to legitimately ferret out ways to increase their freedom on the network. (Some users equate increased freedom with increased productivity, an inaccurate assumption on a properly designed network.) So how do you answer these questions? A network security plan can provide a historical context that tells why you implemented a specific procedure or network rule. Recording a rule and why you implemented it often helps you keep the network security plan up to date. Keeping old rules without apparent reason is counterproductive. On the other hand, too much freedom is an invitation to security problems.

  4. You might find that the goals of management and the network's users don't reflect the goals of the network administrator. A network security plan provides an opportunity for you to express these differences. It also provides the means to discuss reasonable alternatives and compromises. Arguing a particular course of action after you study the ramifications of that action is the only way to create a network that everyone will enjoy using. Rules based on knowledge rather than personal feelings are the best way to later ensure that you know why the rule is in place.

  5. Evenhanded administration of the network means that you enforce the network rules the same way each time someone breaks them. (Some NOSs even provide you with the tools required to detect security breaches in your system. NetWare provides the SECURITY utility for this purpose, for example.) It also means that you explain the rules the same way to everyone who uses the network. Unless you write down the rules, someone could legitimately say that you show a bias toward certain network users or that you make arbitrary decisions regarding some infractions. Clearly written rules alleviate this problem by making the rules, the implementations, any penalties, and its historical context clear to everyone.



Tip: A small company doesn't necessarily need a written security plan. You should at least think these issues through before you start setting up Windows NT, however. A peer-to-peer network needs some type of security plan too. Trying to implement a security plan after installation is fine, but it'll probably cost you extra time to do things this way. Just as you plan your installation in advance, take the time to consider the security needs of your network too.

As you can see, a properly designed and implemented security plan can change the way everyone views the network. There's always a group of people who fail to understand that a security problem on the network costs everyone money. A security plan can handle this situation as well. Even if a user doesn't agree with the implementation of a security feature, he won't want to face any penalties management assigns for failure to follow the rules. Of course, this is the last course of action you want to take. Assigning a penalty might show that a user failed to follow the rules, but it also shows that your plan failed to work in this instance. It's unlikely that you'll ever create a plan that everyone agrees with and no one disobeys, but getting as close as possible to this ideal is the goal you should seek to attain. The following paragraphs provide you with more details about designing and implementing a security plan for your company.

Breaking the Company into Groups


Many companies use a combination of workgroups and a client/server architecture. The workgroup might use Windows NT to implement a small peer-to-peer network just for the people in that section. The client/server network might use NetWare or some other NOS. It allows the company to communicate as a whole.



Tip: It's easy to get confused about the ways in which you need to split your company's various security needs into manageable pieces. Think of workgroups in terms of a group of people working together on a single project. This is a key concept, because they don't necessarily have to come from the same department to be in the same workgroup. Think of security groups as people with similar security needs. You can assign a person to more than one group. They could be part of the engineering workgroup but also be part of the managerial security group, for example. These ideas are separate, and you need to consider them separately.

Whether your company uses several small networks or simply has everyone log into one file server, you'll need to break a large network into smaller pieces before you create a security plan. This helps you organize your company into functional security areas. By breaking the security task into smaller pieces, you can reduce the overall complexity of making your system secure. There are many ways to break the problem into smaller pieces, and you'll probably need to employ more than one of them. The following list provides you with some ideas on how to accomplish this task:



Tip: Always assign someone to manage every workgroup on the network if you have more than one. Let this person take care of some security details by allowing him to assign access for the local workgroup resources. It might also be a good idea to assign someone from the group to manage the print server if the group has one with more than one printer attached. You can't take the time to see to every networking detail, especially when a network starts to grow beyond 100 or so workstations. It'll take a lot of time just to keep the network applications current, keep the workstations up and running, and attend to the myriad other details a network administrator needs to worry about. Making someone in the local workgroup responsible not only reduces your work load, but also helps keep any security measures in place.


Security Plan Considerations


After you break a company into functional groups, it's a good idea to figure out the security needs for each group. Accounting will need much more stringent security than someone who takes care of the company's correspondence. Sometimes you might be able to get by with read-only access for this group. No one would need to edit last year's accounting records, for example, but they might need to refer to them. You might need extra flexibility in an engineering section to promote the flow of ideas from one person to another without giving away new ideas to a competitor. One engineer might have one piece of the puzzle, and that piece could trigger someone else's creative abilities to come up with yet another piece. Inhibiting an engineer with a straitjacket of rules is never a good idea. A management group will need very tight security but will also need the maximum level of access within the group. You can provide management with a straitjacket and actually expect that they'll use it. Hopefully, a manager will understand the need for tight security when discussing the company's future plans.

Besides these considerations, you need to think about special security items within your company. You'll also want to start implementing your security plan. The following steps will help you with both processes. They help you complete a security plan and present some additional ideas that you should consider as you implement it:

  1. Assess company tasks. Even if you do a perfect job of identifying all the groups in your company, you might find that there are still a few tasks the company must perform that fall outside the purview of a group. In many cases, more than one group performs these tasks. Creating the end-of-year report, for example, might require the efforts of several departments in the company. Because this isn't a task the company performs every day, there's no need to create a special group to do it. You do need to consider this type of task when you create your security plan, however. Other examples of task-related groups include special committees and research groups. In this case, several specialists get together to work on a specific problem or idea.

  2. Appoint each person to one or more groups. After you break the company into groups and decide what major additional tasks the company needs to perform, it's time to assign people to them. The finance group maintains accounting records, for example, and the personnel group maintains employee records. In many cases, the assignments you need to make are very straightforward. It's easy to see that everyone in the accounting department will easily fit within the financial group. There are some assignments you might not think about at first, however. You might have someone in personnel who needs assignment to both the financial and the personnel groups, for example. He might need to make entries into the financial program regarding employee raises or terminations.

  3. Brainstorm special user needs. There are other ways to look at your company's security needs—not just from an organizational point of view. Breaking the company into physical and logical units is fine for most security needs. Doing so allows the network administrator to work with both management and network users to make reasonable security assignments based on fact. In some situations, a lack of information prevents you from making reasonable assignments. What if a user is just starting a new project, for example? He certainly won't know what types of access he'll require on the network, because he's never tried to perform that task before. The manager might have a reasonable idea of what type of access the user requires, but this is mere conjecture. You'll find yourself at a loss to make a reasonable assignment without more information. Unless you want to spend a lot of time retuning your network to compensate for these situations, you might want to take the time to brainstorm the user's needs.

I'd like to look at that third step in more detail. It's the last one you need to complete your security plan. After you do figure out special user needs, you have all the information required to make the plan work. Brainstorming is a think-tank approach to network management. It's a tried-and-true method used in many other ventures. Essentially, you define a task based on past knowledge of similar tasks and on future goals. You answer questions such as, "What do we plan to achieve?" and "How do we plan to achieve these goals?" You must consider what tools you have available on your network to get the job done. This includes both hardware and software resources. You should also throw out ideas for consideration. Someone might need to play the part of devil's advocate to make sure that you consider both the positive and negative aspects of a particular decision. Of course, you want to use this approach only if there's insufficient information on which to base a decision using standard techniques. You can take a number of steps to make this process work properly:

  1. Break the user's task into logical elements. What types of applications does the user need to use, for example? Each application involves a different set of security rights. Perhaps one or more groups already provide these rights on the network. (Whenever possible, try to avoid making non-group assignments.)

  2. Create a list of equipment the user needs to access. Does the user need to use a fax or a special printer, for example? If the security system on the network limits access to these items, you might need to provide the user with the special access required to use them.

  3. Write down a list of tasks the user needs to perform. Sometimes you'll see a special application or a piece of equipment the user will need to use to accomplish a task. Make sure that you don't just list these tasks. Describe the tasks so that everyone is talking about the same task.

  4. Look for areas where the user might have too much access. After you figure out where the user might need access, trim your list to areas where the user must have access to get the job done. There's no reason to give someone too much network access simply because he's starting a new project.

As you can see, brainstorming a task can really help in a situation where you lack the information needed to make a good decision using just the available facts. You need to realize that your group bases such decisions on conjecture and derived information. Keep in touch with the user as he gets further into his project. You might find that you can reduce his access in some areas and that he requires additional access in other areas. (The user normally will tell you when he doesn't have enough access but seldom will he tell you if he has too much access.) Remember that it's your responsibility to make sure that the user has enough access but not too much. Some users will try to convince you that they need additional rights to certain areas when they really don't.



Peter's Principle: Delegating Network Administration Tasks

You've gotten your network installed and all the Windows NT workgroups are in place. So why are you still running around like the proverbial headless chicken? Windows NT provides a lot of tools to help the administrator manage a network. We learned in Chapter 21, "Peer-to-Peer Networking," that these tools pertain not only to Windows NT peer-to-peer installations, but to other types of networks as well. You can install agents to monitor the status of a workstation remotely or through a local host. You can use all kinds of connections to get a bird's-eye view of your network. Yet even with all these aids, you feel out-of-touch and barely able to maintain the system.

Some network administrators are under the impression that they can maintain the entire network themselves given enough time and tools to do the job. The truth of the matter is that only Superman (or Wonder Woman) can fulfill all the needs of some networks. This includes the area of network security. Although you won't want to give anyone rights they don't need, you might find that you require help to maintain a large network. How much help you need and what size of network can be defined as large is primarily a matter of network complexity and whether you are a full-time network administrator. If management gives you a few hours each day to perform network duties and you wear another hat for the rest of the day, a large network could be as few as 20 users. Even a full-time administrator will begin to feel the pinch at around 100 users, especially if your company performs a wide variety of tasks with a conglomeration of equipment.

There are a few problems in allowing other people to help you maintain network security. Centralized control of the network for security purposes is a real advantage. If one person is responsible to management for ensuring that network security remains high, there's little possibility that he'll do a halfhearted job. In addition, centralized control means that fewer problems will slip through the cracks. Users will never wonder who they should ask for more rights on the network. They'll always know the one person who can help them.

I always follow a simple principle when it comes to network security. Always maintain control. When you can't maintain control, find out why. You might find that it's a problem with a network administrator who's overwhelmed with requests for service and little time to really take care of the network. Don't kill the security plan that you worked so hard to create. Give the network administrator sufficient help the get the job done.



Customizing the Log-on Sequence


Now that we've gotten a bird's-eye view of security, let's look at what Windows NT can do to help. I was pleasantly surprised by all the features Windows NT provides, especially when you compare them to what Windows 95 provides. When using a share level of user access, for example, Windows 95 provides the capability to assign two levels of password protection to every resource. This is nice and will probably work fine for a small peer-to-peer network. The stricter user level of access will definitely improve the situation but still doesn't compare to the level of support provided by Windows NT. The level of protection provided by Windows NT is more in line with what you'd find in client/server networks like NetWare. Not only is the drive (or other resource) full protected, but individual files are protected as well. In addition, Windows NT provides four levels of access in place of the two levels found in Windows 95.

There are other problems with Windows 95 as well. The inability to assign a password to a specific file didn't sit well with me, for example. Sometimes you need to protect one file in a directory but not another. Some older applications really need to have their configuration files in the same directory as the rest of the executables. I usually like to make my executable files read-only so that the user doesn't erase them. Windows NT will help you overcome some of these problems.

So what will this added security cost you? This is one area where you'll definitely have to make a decision between security and the capability to run a variety of application types. Windows 95 is definitely more flexible when it comes to running applications than Windows NT. It also provides adequate security in all but the most demanding situations. You have to decide whether you want to give up the added flexibility to gain the security features Windows NT provides. There is another cost involved here as well. I'll show you in just a bit how security works under Windows NT at a low level. You have to ask yourself just how much that added security is affecting system throughput. I think that you'll find it's quite noticeable. I don't want to get into just how great that effect is because every system is different. Even if the system wasn't different, the way each user works with the system is different. I think it's sufficient to know that part of the cost of using Windows NT is lost processor cycles—speed that you could be using to execute applications.

Security is a Windows NT forte. I think it's important to take a good hard look at what these features are so that you can make the best use of them as you design your security plan. The following sections describe these features. In some cases, I've described how to use and implement these features in other chapters, so I won't cover those aspects again here. I'll show you how to use the features Windows NT provides to implement the security plan that I talked about in the preceding section.

Logon


The best way to prevent a security breach is to keep someone from getting onto the network in the first place. The dialog box you see when you start Windows NT is your first line of defense against someone who would try to break into your system. I've talked about the log-on feature of Windows NT in several places. We looked at it as part of the Control Panel applets in Chapter 2, "Exploring the Interface," and again in Chapter 21. Let's take a look at how you can actually use the Welcome (log-on) dialog box to help implement a security strategy.

Stand-Alone Security

It always amazes me when someone asks why it's important to take the time to protect a stand-alone workstation. Does the fact that a workstation doesn't connect to the network reduce the quality of the data it contains? The only part of the security picture that has changed is that a stand-alone workstation will at least keep someone from accessing your data on the network. The fact that many stand-alone workstations contain valuable data is still very important. In fact, I think you'll find that most stand-alone machines at your company are either relics that no one wants to use or engineering workstations that no one wants to expose to the security risks of network use. Either way, if your stand-alone machine has Windows NT on it, it's pretty certain that the data it contains is valuable.

Fortunately, Windows NT does provide a modicum of protection as a default. Everyone who logs into a stand-alone machine will have to have an account and password. I'll show you in a bit how to add new users to a machine using the User Manager. All this is for naught, however, if the user assigns a wimpy password to his account. Make sure that you place a provision in the account for frequent password changes and force a password of a specific length. You'll also want to provide password guidelines as part of your security plan. I normally state that a good password consists of two unconnected words separated by some non-alpha character. TREE?SUNSET is an example of a password that someone could easily remember but would be very tough to break. I normally recommend a minimum of 10 characters in any password—some situations call for even longer passwords.



Tip: If security for a specific workstation is so important that software alone won't take care of the problem, consider one of several alternative solutions. You could add a locking bolt to the back of the machine to prevent people from opening it , for example, and use the BIOS password feature to prevent access by any means until the user provides the correct password. Physical locking mechanisms are also available. One of them goes over the floppy disk drive to prevent the user from accessing it. You can also add a lock to a standard PC On/Off switch. Unfortunately, most of these solutions are expensive or inconvenient or both. It's almost always worth your while to seek other solutions to the problem.

Of course, just enabling passwords doesn't help you very much. A disgruntled user who does have access to the stand-alone workstation could still do a considerable amount of damage; the fact that they would probably get caught really doesn't provide much of a deterrent in some cases. I always back up my configuration changes with a policy change to go with the password setting. This means opening Explorer and using the File Properties dialog box to turn off various types of access. (See the "Using the Security Page of the File or Folder Properties Dialog Box" section later in this chapter for further details.) You can remove all access to an individual Control Panel applet by removing access to its CPL file, for example. There's one CPL file in the SYSTEM32 folder for each applet, and most of the names are pretty easy to figure out. Table 23.1 provides a list of the more common file names and their purposes. If you don't see a CPL file here that you need to identify, simply double-click on the file to see what it looks like. Double-clicking opens it just as if you're in the Control Panel.

Table 23.1. Common CPL names for Control Panel applets.

File Name Contains Description
ACCESS.CPL Accessibility Options This applet displays the Accessibility Properties dialog box—the one you use to add MouseKeys and other accessibility features to your installation.
APWIZ.CPL Add/Remove Applications You'll see the Add/Remove Programs Properties dialog box when you double-click on this file. There are two pages to this dialog box: one for standard Windows applications and another for Windows-specific installation options.
CONSOLE.CPL Console We used the Console Windows Properties dialog box provided by this applet to control the appearance of DOS applications when run in a window.
DESK.CPL Display There are several ways to access the Display Properties dialog box provided by this applet. One shortcut that we looked at is to right-click on the desktop and choose Properties from the context menu. Of course, this applet also appears in the Control Panel. The reason I mention the multiple access techniques is that you can remove Control Panel access and still allow the user access to this applet by using the right-click method.
DEVAPPS.CPL PC Card (PCMCIA) Anyone who has a PCMCIA bus on his machine will be able to access this applet. It allows you to configure the bus for use.
INTL.CPL Regional Settings You'll see the Regional Settings Properties dialog box during installation. It allows you to select a time zone, currency, and other international features for your computer.
MAIN.CPL Mouse This is the applet that displays the Mouse Properties dialog box you use to set up your mouse for use. Because there aren't any desktop shortcuts to this particular applet, you can always set up a separate shortcut in the user's Start menu. I talked about shortcuts in Chapter 5, "Startup Shortcuts." You'll want to check out the Create Shortcut option of the context menu for the Control Panel applets if you decide to go this route.
MLCFG32.CPL Mail and Fax This is another one of the applets you can access from another location. In this case, it displays the MS Exchange Settings Properties dialog box we used to configure Microsoft Exchange. We talked about Microsoft Exchange in Chapter 18, "Talking to the Outside World."
MMSYS.CPL Multimedia Double-clicking on this file displays the Multimedia Properties dialog box we talked about in Chapter 16, "Multimedia Under Windows NT."
MODEM.CPL Modem You can get to the Modem Properties dialog box from a variety of places, too, including from within Microsoft Exchange.
NCPA.CPL Network This applet displays the same Network dialog box you get when you right-click the Network Neighborhood icon and select Properties.
NWC.CPL CSNW Installing NetWare support on your computer adds a special applet that displays the Client Service for NetWare dialog box. You'll normally see this dialog box right after you install the service. It allows you to select a preferred server and other connection features, such as print options. You'll also find the NDS tree and context settings here. Obviously, this is one of the applets you'll probably want to lock away for safe keeping.
PORTS.CPL Ports We looked at the Ports dialog box you display with this applet in Chapter 14, "Exploiting Your Hardware." It displays a list of ports and allows you to configure them.
SRVMGR.CPL Server Opening this applet displays the Server dialog box I talked about in Chapter 2 and fully described in Chapter 22. In most cases, you'll want to keep access to this applet restricted to administrators because even a power user doesn't really require access to it.
SYSCPL.CPL System This applet displays the Server dialog box we used to change Windows NT environment settings. We also used this dialog box to change the virtual memory, tasking, and recovery settings. Needless to say, you'll probably want to restrict access to this applet. Of course, the level of restriction depends on who you think should manage the environment and other settings. I normally allow power users to access this applet because they might need to change the Windows NT environment settings from time to time.
TELEPHON.CPL Telephony This applet provides access to the Dialing Properties dialog box I described in Chapter 17, "Windows NT Connections." You can access this dialog box from several places beside the Control Panel—including most of the Microsoft Exchange-related programs.
WGPOCPL.CPL Microsoft Mail Postoffice I've talked about the Microsoft Workgroup Postoffice Admin dialog box in the past. (Chapter 18 is one of the places we look at this utility.) That's what this particular applet provides access to. You'll probably want to restrict access to those people who actually administer the postoffice. Unfortunately, you can't access this applet from anywhere else, so you'll need to create a shortcut for those users who need to access it but don't require general Control Panel access.

Security doesn't stop at simply removing applet access under Windows NT. You can go further and simply remove access to the Control Panel itself by controlling access to the CONTROL.EXE file in the SYSTEM32 folder. I normally restrict access to power users or those folks who have a specific need to access it. Under Windows 95, you have the option of providing full or partial access to a particular applet; Windows NT provides a lot more flexible access to these applets. You can even provide a modicum of access to the applet. Allowing the users Read access, for example, lets them see the applet settings in most cases but not change them.



Tip: The System Policy Editor strategy used by Windows 95 is totally different than the Windows NT security strategy discussed in this chapter. Although the Windows NT strategy is a lot stronger and more flexible than the one used by Windows 95, I also found it counterintuitive to use. Make sure that you study both techniques if your network contains a combination of both workstation types.

You should follow a few other simple security procedures as well. How often do you leave your workstation to take care of some "quick" task without locking it first, for example? Those few seconds could allow someone to add a Trojan Horse program (an application designed to break down security by posing as a part of the normal login process or a security dialog box) to the computer. It takes just a few seconds to start the screen saver with password protection; why not use this feature to your advantage? Better yet, log out of the computer before you leave—it only takes a few seconds to log back in. We'll look at these security precautions in more detail later in the chapter.

Peer-to-Peer Security

All the security policies I covered in the "Stand-Alone Security" section apply here as well, but there are several important differences. For one thing, you've got to deal with other people accessing your machine from remote locations. In this case, it'll be someone from your own workgroup (I'll cover company-wide connections in the next section). You've also got to consider your rights on other people's machines. It's one thing to protect your own machine to guard against data theft, but how will you feel about the policies used by other people? Obviously, there has to be some middle ground here and you'll need to find it.



Tip: The government uses a policy of need to know in regard to its security policies. Considering the vast amount of information the government has to safeguard and the number of people who require access to it, that policy seems to work pretty well for the most part. Using a need-to-know policy within a workgroup might seem a bit harsh; you might want to give everyone access to everything on your machine. That's where security breeches start, however. I don't want to give you the idea that you need to follow on the heels of "big brother," but you do need to exercise restraint when granting access to your machine. Try a need-to-know policy for a bit, and I think you'll find that it works pretty well. It'll give everyone the access they need yet reduce the holes in your security to an acceptable level.

Obviously, the first line of defense you have against unwanted intrusion is a combination of accounts and passwords. You'll want to check on these accounts at regular intervals and get rid of any that you don't need any more. Dead accounts are one of the ways people keep covert activities on your machine a secret. Because you don't monitor the dead account, you won't think to check it for potential problems when you notice a breach in security.

We'll discuss the second line of defense in a few moments. Take a look at the "Using the Security Page of the File or Folder Properties Dialog Box" section of this chapter. Assigning the right kind of security to each resource on your machine becomes essential as you open it for access by others. If you don't want to share a resource, make sure that you define any shares for it. (Unlike Windows 95, Windows NT defines some default shares that you can't remove. They're used by the operating system for a variety of purposes, including remote monitoring by the network administrator.

Windows NT also allows you to audit user files. I'll show you how to do this in the "Managing User Accounts" section of this chapter. I feel that certain kinds of auditing are especially important on a peer-to-peer network. How likely is it that someone will have to attempt logging in four or five times, for example? Not very. If you monitor logoff and logon failures, you'll be able to see unsuccessful attempts to access the workstation. These unsuccessful attempts may simply show that someone forgot his password. More likely than not, though, it shows someone trying to break into your machine. You should also monitor attempts by other people to change the security policies you've set and other system-specific access. No one but an administrator should even attempt to change security on your machine, so attempts in this area are important events to track.



Tip: It might not seem like a very big deal to keep a Guest account on your machine, but it is. Hackers always look for the Guest, Administrator, and Supervisor accounts on any system they want to break into. By keeping a Guest account, you've already given a hacker the first piece of information he needs to break through your defenses (a user name). An administrator account usually has good password protection because it's an obvious hole in the security net. You'll find that administrator accounts usually are checked on a more consistent basis as well. Most people use an easy password for the Guest account, however, to make access to it easier when a lot of people need to share a resource on a machine. Not only does the easy password make life easier for the hacker, but it's less likely you'll figure out who it is. How do you know the person's name? He logged in under Guest, so there isn't any easy way to monitor access. Always give each person who accesses your machine a separate account under his own name and make certain that he uses an appropriate password to protect that account.

OK, this is all fine and well from a theoretical point of view, but what if the NOS won't allow you to remove the Guest account (Windows NT won't)? I get around this problem by removing all rights, even the Guest group rights, from the Guest account. That way, even if someone does manage to break into your system using the Guest account, he won't be able to do anything.


Peer-to-peer networks also need to consider the machine settings. How do you want the various machines to talk to each other, for example, and which protocols will they use? We covered many of these issues in Chapter 19, "Surfing the Net." Other settings will be discussed in the following sections. The important thing to see right now is the overall picture.

Client/Server Security

As I mentioned earlier, you can use the same settings I described in the "Stand-Alone Security" section with a client/server security setup for a NOS, such as NetWare or Windows NT Server. You can also add the peer-to-peer networking security I described in the preceding section.

Windows NT provides some additional capabilities for client-server setups that I didn't describe earlier. All these capabilities appear as part of the connection itself. You can read about these additional features in Chapter 19. You can implement a remote monitor using SNMP, for example.

The major security issues for client/server networking are handled by the server itself. I'm already showing you most of the features the server version of Windows NT provides as part of this chapter. The important thing to remember is that the server version enhances the capabilities of the workstation version.



Peter's Principle: File Servers—The Private Parts of a Network

I work a lot with small businesses that insist on keeping their file server right out in the open where anyone can see it. My first visit usually convinces them to change that policy. After getting permission, I usually send everyone out of the room and proceed to not only break into the file server, but lock everyone else out in a matter of minutes. I'm not talking about a long time here: five or six minutes usually gets the job done. My only tool is a copy of DEBUG (which I show the network administrator). Consider how long it takes you to get a cup of coffee. Could someone break into your system in the time it takes you to perform that task?

Now you might think that I've used some deep, dark secret to break into that computer. Nothing could be further from the truth. I'm simply using a technique that Novell actually taught in the Certified Novell Engineer (CNE) courses. It was shown as a means for a CNE to help a user get back into his system if he accidentally forgot his password. (Novell no longer teaches this technique as part of its courses.)

Before you get the idea that NetWare is less than secure, consider that you can break into just about any file server if you know how. It's important to realize that any file server is a sitting duck to someone who really wants to get into it. All it takes is time and a little luck on the part of the perpetrator. A file server is only secure if you keep it physically locked away. Place it in a locked closet if nothing else.

You can do other things to make life difficult for someone wanting to break in. Ever try to access a computer without a keyboard? You can actually remove the keyboard from most servers after you get them running. In fact, there are locks that you can place over the keyboard hole, making it next to impossible for someone to plug another keyboard in.

The important thing to remember is that physical server security goes hand in hand with other parts of your security plan. If you decide to leave your file server exposed, you have no one but yourself to blame when someone breaks in.


NetWare also provides a host of security features you can implement on a group, directory, or file level. Novell's group rights work about the same as those in Windows NT. It also includes the idea of a trustee—someone entrusted to guard a specific resource. Finally, you can make someone equivalent to someone else. The second person gains whatever rights the first person has in addition to his own. This is called a security equivalence. So what are the rights provided by NetWare groups, trustee rights, and directory rights? Table 23.2 tells you all about them.

Table 23.2. NetWare security levels.

Right Description
Supervisory This right gives the person all rights to the directory, its files, and subdirectories. It overrides the inherited rights mask (IRM). It also allows the user to grant or modify any rights in the IRM when used with a file.
Read Allows the user to read either an individual file or all the files in a directory.
Write Allows the user to write to an individual file or any file in the directory. The file must already exist unless the user also has the create right. You can quickly get into trouble with this right. Word processing programs, for example, typically rename the existing file and then create a new file to store the data a user types. If you don't give the user the read, modify, write, and create rights, he won't be able to use his word processor. The read and write rights are pretty obvious, but some newer administrators might not think about the create and modify rights.
Create NetWare looks at creating files as a different right than simply writing them. If you create a new file, for example, you can write to it as long as it's open. After you close the file, you need the write right to reopen it and modify the file's contents. There are situations in which you wouldn't want to give a user both rights. Giving someone the create right without adding the write right, for example, allows you to perform a survey in which the user can't change his answers after he exits the survey program.
Erase This right allows you to delete an individual file or any of the files in a directory. You can allow a user to erase an individual file by giving him that right at the file level but revoking the erase right at the directory level.
Modify Use this right to allow the user to change any of the file's or directory's attributes. If you add the hidden attribute, for example, DOS won't display the file when you use the DIR command. NetWare utilities tend to ignore file and directory attributes in favor of the IRM. This right also allows the user to change the name of a directory or file. He'll have to have it to use some types of applications, such as word processors.
File Scan A user needs this right to see the contents of a directory or an individual file name within the directory. The file scan right is like the hidden file attribute; the difference is that it affects both DOS and NetWare utilities.
Access Control This right is just like the supervisory right, except that it also allows the user to change the trustee assignments for a directory or file. Giving the owner of a directory or file the supervisory right is fine. Giving him this right affects your ability to manage the network properly. The network administrator has to maintain the right to assign trustee rights.

Obviously, I can't tell you about every security feature of every major network on the market; I can't think of any book that provides that level of information. However, I wanted to make you aware of the fact that security is a major issue in the client/server environment. You need to implement the full security package provided by your NOS to make your network secure. This means spending time looking through the manuals and then actually implementing the features you read about.

Master Key


What do I mean by a master key? This is a policy more than a feature. Suppose that your company uses a combination of client/server and peer-to-peer networks. It's important to keep things as simple as possible for the user yet to make maximum use of company resources and provide the needed level of flexibility.

Trying to get any user to remember more than one login password is difficult. It also wastes time in some respects, because the user will spend a lot of time logging into the various networks he needs to access. Also, there's a frustration factor to consider as the user goes from login screen to login screen. Do you really want to frustrate a user who is trying to help you implement a security strategy?

Windows NT provides the capability to use one master key to get to all the networks a user can access. A master key allows the user to enter one password to access all the resources he needs. The old system was to use a different password for each resource. If you needed to log into the workgroup network, you needed one password. Another password would give you access to the company network. You needed still another password for your mail program and yet another for your communications program. Even if the user used the same password for every access, it was inconvenient, to say the least, to enter a password every time you required access to something. Windows NT remembers all the users' passwords and enters them automatically as needed. All the user needs to do is enter the initial password when starting Windows NT. Implementing a master key strategy is simple. All you need to do is have the user provide precisely the same password to every login screen the first time he goes through them. I stress the word precisely here because capitalization makes a difference on some networks.

After you do this the first time, Windows NT remembers the master key and uses it to log the user into every network he has access to. Instead of going through a long, frustrating procedure, the user sees one consolidated Welcome dialog box at the beginning of his Windows NT session. This one password is all he'll need to use the full flexibility of the network.

Locking Your Workstation


No one sits like a statue guarding his workstation all day long; it's ridiculous to even think of such an idea. We all have to get up to attend meetings or eat lunch. Locking your workstation is the only way to ensure that no one will touch it while you're gone. There are several things I could mean by this, but there are only two ways to lock your workstation with any certainty.

I once ran into someone who disliked using the password locking providing by his screen saver. His alternative was to physically lock the computer using the key lock that most computers have. The only problem with this solution is that those locks are hardly safe. Every computer I've ever looked at uses the same key for the lock, making it possible for anyone with a key to break your security. If you go to the expense of replacing that lock with something that uses a unique key, you might be able to get by with just locking your system. The question remains, though, why bother when you have a perfectly good screen saver locking mechanism at your disposal?

Let's take a look at what you need to do to implement screen saver security. If you right-click on your desktop, choose Properties from the context menu, then select the Screen Saver page, you'll see a dialog box similar to the one shown in Figure 23.1. Check the Password Protected checkbox and your machine will be protected any time you leave for a few minutes.

Figure 23.1. You can use the Screen Saver page of the Display Properties dialog box to add password protection to the screen saver.

Obviously, there's more to locking your workstation than simply adding password protection to your screen saver. One of the things you need to think about is that your screen saver won't start working right away; it takes a few minutes to activate. Pressing Ctrl+Shift+S activates the Windows screen saver immediately. Whenever you leave your workstation for a meeting, simply press Ctrl+Shift+S to start the screen saver first.

Getting back into your workstation is easy. Move your mouse or press a key on the keyboard to display the Workstation Locked dialog box. It gives you the instructions you need to log back in. All you need to do is press Ctrl+Alt+Del. You'll see the standard password dialog box at this point. Just type your password and the workstation is unlocked. Needless to say, you'll find that this is a lot more secure than those key locks.

So how does this procedure differ from logging off? When you log out of the workstation, Windows NT has to reinitialize everything. If you use the screen saver option, all your open applications remain just as you left them. The only thing you need to do is type the password to display them again.

Logging Off Versus Shutting Down


The Start menu contains a Shutdown entry that you've probably used several times as you've looked through this book. Choosing this option displays the Shut Down Windows dialog box shown in Figure 23.2. I wanted to spend just a few seconds talking about how this dialog box affects security.

Figure 23.2. The Shut Down Windows dialog box contains three entries that allow you to end your current Windows NT session.

The first thing you need to realize is that logging out is a bit more secure than relying on screen saver security. The reason is simple: If someone does manage to break your password, he'll be starting out with a clean display. When you use screen saver security, the hacker sees the desktop just as you left it—open files and all.

There's another form of security, though, that you need to consider. If you select the Shut Down the Computer or Restart the Computer option, Windows NT automatically writes any data in the disk cache to your hard drive. This means that any changes you make to the security policies also are written to disk. On the other hand, selecting the Close All Programs and Log On as a Different User option just closes the current session. It doesn't necessarily save the disk cache immediately.

Managing User Accounts


We've looked at all the theoretical areas of security plus a few security options you should exercise as a user. Now it's time to look at the process of managing users from the total workstation point of view. You'll need Administrator level rights to really use this section of the chapter. Having access to the User Manager utility in the Administration folder might let you participate marginally if you don't have these rights. Start by opening the User Manager utility; you'll see the dialog box shown in Figure 23.3. Notice that the dialog box contains two main sections: Username and Groups. The Username section provides a list of everyone who can access your system. The Group section contains a minimum of the default group definitions Windows NT provides. If you've defined any local groups, you'll see them here as well.

Figure 23.3. The User Manager utility allows you to set specific levels of access for each user on your workstation.

Managing security under Windows NT begins at the group level. I'm not talking about workgroups here. A group in the security sense of the word is one or more people who have a specific set of rights. The rights you gain in one group are cumulative with the other groups that you belong to. If you belong to the Power Users group, for example, you can change the system time. If you are added to the Backup Operators group, you can also perform a system backup. It's important to know what kinds of access the various default groups provide. Table 23.3 provides a brief description of each group. You'll also want to look at the "User Rights" section of this chapter to see how you can obtain detailed information about the various rights each group has.

Table 23.3. Default Windows NT security groups.

Group Description
Administrators The best way to describe this category is total access. It's the only default group that can do everything Windows NT allows. An administrator can act as part of the operating system, for example—a right no one else has. You also have to be an administrator to add workstations to the domain. I always assign at least one person (preferably, two) this right during the setup process.
Backup Operators This is a standard user with the special rights required to perform a backup of the machine. The backup operator is the only one besides the administrator who can back up and restore files and directories. I'll show you in a bit how you can give power users the right to perform backups, but it's important to know that this group has a default right that you'll need to assign to the person who performs backups on your machine. Of course, in most cases, the administrator performs backups in all but the largest companies, so you won't have a problem in this area.
Guests All this group can really do is login to the machine and log back off.
Power Users A power user is someone you trust not to cause problems on the workstation. He's also a bit more knowledgeable than the average user. A power user can do things like profile the performance of a single process and force a shutdown from a remote system. You'll want to use this particular group with care; giving it only to people who really know what they're doing.
Replicator This is another specialty group like Backup Operators. It allows the individual to perform file and directory replication within the domain.
Users A beginner user will become part of this group. It allows you to do the basic things needed to perform work within Windows NT but not to change any of the system settings. In fact, this particular group can't even change the system time. I usually assign this group to new users with a lower skill level. After a user becomes familiar with Windows NT and I know that I can trust him, I add him to the Power Users group.
Everyone This is a special group that doesn't appear in Figure 23.3. It's a super group that includes all the other groups. Every time you see this group listed somewhere, you know that it includes all the groups in this table plus any local groups you've defined.

Now that you have a better idea about the basis of security under Windows NT, let's look at some management specifics. The following sections provide the details about managing users with the User Manager utility. I'm assuming that you already have User Manager open as a prerequisite to using the procedures in each section.

Adding New Users


One of the first things you need to learn to do as an administrator is add new users. In fact, when you install Windows NT, it only comes with two users: Guest and Administrator. Before you add new users, though, make sure that you have a security policy in place and that you've determined which users to add. You'll also want to have an idea of what types of work they'll perform with the workstation, because that determines what rights they need.



Tip: You can reduce the amount of time required to add a new user or group by selecting a user or group with similar properties and pressing F8. User Manager creates a new entry with the same properties as the existing user or group and automatically display the appropriate dialog box for editing it.

To add a new user, follow these steps:

  1. Choose the User | New User command to display the dialog box shown in Figure 23.4. This is where you'll add the user identification information, such as the user's name. I've already filled out this dialog box to give you some idea of how to use the various fields. The Username field specifies how the user will log into the workstation and how other users will see this person on the network. I've had users ask to use a nickname in place of their first name, and I don't see any problem with doing so. The full name usually contains the user's full name; it's what the administrator uses to identify the user.

    Figure 23.4. You use the New User dialog box to define the user identification information and password restrictions.

  2. Enter a password once in the Password field and then a second time in the Confirm Password field. I normally use a default password here, such as DAY*NIGHT. Notice that I don't use something silly like SECRET or MASTER. Those passwords aren't secure if you provide outside access to a machine. Always use a standard password to make it easier for you to remember what it is, but use something nonstandard to provide a bit of security.

  3. Select the password restrictions from the four checkboxes at the bottom of the dialog box. I usually enable the User Must Change Password at Next Logon checkbox to force the user to enter a new password the first time he logs into the network. That way, he can't say that anyone (even the administrator) has access to his account unless he gives his password out. I've also never figured out why Microsoft added the User Cannot Change Password checkbox unless some company has an overdeveloped "big brother" syndrome out there. It's available if you want to assign the user a password and force him to keep it forever. Notice that you can also disable a user's account—a handy feature if he has broken security in some way and you want to make sure that no one can access the account.

  4. Click the Groups button to access the Group Memberships dialog box shown in Figure 23.5. This is where you'll define what groups the user belongs to. The Member Of box contains the groups the user currently belongs to. The Not Member Of box contains a list of available groups. You'll want to spend some time learning about the rights each group has before you start assigning them to people. Most of the group names (as we saw in Table 23.3) are pretty self-explanatory. Notice that Windows NT provides a default group membership to the Users group.

    Figure 23.5. The Group Memberships dialog box helps you define the user's security restrictions.

  5. Assign the user to various groups, depending on his particular needs. If you want to add a group, simply select it from the Not Member Of listbox and click Add. If you want to remove group access, select a group in the Member Of listbox and click Remove. After you complete the group selection, click OK to accept the changes.

  6. The New User dialog box appears. Click the Profile button. You'll see the User Environment Profile dialog box shown in Figure 23.6. This dialog box contains two sections. The first section defines the Windows NT version of script processing (I'll tell you more about this in a second). The second section defines the user home directory.

    Figure 23.6. The User Environment Profile dialog box contains the environment settings for the user.

  7. Type the path and script name you want Windows NT to process each time the user logs in. A script contains any batch-processing commands you want Windows NT to perform. You can use a BAT (batch), CMD (OS/2 command), or EXE (executable) file for scripts.



    Note: Users who log into a NetWare network don't need an entry here because you can perform script processing when they log into the file server. Chapter 22 has details on how to do this. There is nothing to stop you from processing both a Windows NT script and a NetWare script, however.

  8. Select the Local Path or Connect radio buttons in the Home Directory group. You'll use Local Path for stand-alone workstations or those that won't necessarily log into a file server. In this case, you'll need to supply a path to a local drive. Windows NT uses a default setting of the \USERS\DEFAULT folder if you don't supply a path. Use the Connect radio button for users who always log into a file server. If you select this option, choose a drive mapping from the drop-down listbox. Add a path to the user's home directory on the file server. You'll need to use a UNC path for the home directory. If you use a NetWare file server, for example, the UNC name might look like this: \\DATACON\SYS\JOE. DATACON is the file sever name, SYS is the volume name, and JOE is the path to the user's home directory.

  9. Click OK to return to the New User dialog box. Click OK again to add the new user. The new user should appear in the Username section of the User Manger window.


Adding New Groups


I've found that the default groups Windows NT provides cover a wide variety of situations. There have been a few situations where I needed to provide a few new groups. One company that I worked with wanted a special Programmer group. This group had all the same capabilities of a Power User, with the added capability to back up files. They didn't want to use a combination of Power User and Backup Operator because the Programmer wasn't supposed to restore files and directories. Programmers also needed some of the Administrator rights to test security features in the applications they wrote.

Whatever the reason for adding a new group, User Manager makes it pretty simple to do so:

  1. Choose the User | New Local Group command to display the New Local Group dialog box shown in Figure 23.7. Notice that the dialog box automatically includes any users you had highlighted in the user area of the User Manager window in the Members listbox.

    Figure 23.7. The New Local Group dialog box is where you begin the process of adding a new group.

  2. Type a group name and description in the first two fields. Make sure that the group name is self-explanatory and that the Description field contains a summary of the access this group provides.

  3. If you need to add more members to the group, click the Add button. You'll see an Add Users and Groups dialog box like the one shown in Figure 23.8. This dialog box automatically displays a list of users on the local computer. You can use the List Names From drop-down listbox to select another computer as a source of names. (As of this writing, you'll only see other Windows NT workstations or servers in the current domain listed.) There won't be any groups listed, because you're adding members to a group. I show you how the groups fit into the picture as part of the "User Rights" section. Because there aren't any groups, the Members button is disabled as well.

    Figure 23.8. You use the Add Users and Groups dialog box to select new users for membership in the current group.

  4. Highlight one or more users in the list and click Add. You should see a list of users added to the Add Names listbox. If you need to search for a particular user, just click the Search button. You'll see a Find Account dialog box like the one shown in Figure 23.9. Type a user's name and click Search. You'll see a list of matching names in the Search Results box.

    Figure 23.9. You can use the Find Account dialog box to search for a particular user. User Manager allows you to check all machines or just a particular machine for the user name.

  5. Click OK to complete the selection process. Click OK again to add the new group to the list of groups in the User Manager window. We aren't done yet; the new group you created doesn't have any rights except those available to the Everyone group. What you need to do now is add the appropriate rights to the new group.

  6. Add rights to the new group using the procedure in the "User Rights" section of the chapter. Essentially, what you need to do is add the new group to each right separately.


Removing a User or Group


Removing a user or group is easy. All you need to do is highlight the user or group you want to remove and press Delete. You'll see a dialog box similar to the one in Figure 23.10. Notice that this is the one you'll see when deleting a user; the group version is very similar to this one. Click OK to clear the warning dialog box, and the user or group will be gone.

Figure 23.10. User Manager always provides a warning message before it removes a user or group.

Warning: Removing a user or group is permanent. Even if you create a user or group with the same name, you'll have to redefine all the new entry's properties. Make sure that you want to remove a user or group before actually doing so.

Changing a User's or Group's Properties


You can double-click an existing entry to change its properties as needed. You'll see the same dialog box you used to create the user or group. Change the properties you need to change and click OK to make the changes permanent.

Setting Policies


Polices provide a method for deciding how Windows NT sets up security on a global basis. In fact, it's the software equivalent of the security plan we previously discussed for a single machine. A policy affects everyone on the local machine, so it's important to carefully think about any changes you make.

I like to think of a security plan as the specification and policies as the implementation of that specification. Obviously, the security plan contains more information than you'll find here, but it does set the tone for what you'll do here. As with everything else we've covered so far, you set policies within the User Manager. The following sections describe the three Policy menu options. I'll assume that you have User Manager open.

Account

Choosing the Policies | Account command in User Manager displays the dialog box shown in Figure 23.11. There are several sections, and most of the options relate to how Windows NT works with passwords.

Figure 23.11. The Account Policy dialog box specifies how Windows NT reacts to user access situations.



Note: Unlike many other NOSs on the market, Windows NT uses a case-sensitive password. For example, Total*Recall is a different password than TOTAL*RECALL. Make sure that your users realize this, or they won't be able to figure out why the computer won't give them access. I've had several situations in which the previous user left Caps Lock on and the next user experienced problems logging in because he had selected a lowercase password.

The first group in the Account Policy dialog box is Password Restrictions. This group affects the way that Windows NT maintains the user's password. The first things you'll want to check are the Minimum and Maximum Password Age settings. I always let the user change his password. In fact, the user should be allowed to change his password whenever he wants to because this only promotes good security. On the other hand, most users never think to change their passwords unless you force them to. You'll want to set the Maximum Password Age to something consistent with your company's security plan. I normally set this to 14 or 30 days, depending on the level of security the company needs.

Notice that the Minimum Password Length group contains an option for a blank password. Never select this option unless your company is totally disinterested in security. I can assure you that a user will always select a blank password if he can get by with it. Windows NT still displays a password screen when the user tries to access it, but he'll just press Enter to get past it. A good password contains between 5 to 10 characters. I normally go for a bit better security by insisting on 10 characters or more. Obviously, this eliminates a lot of the really simple passwords, such as SECRET, from the list. In fact, the 10 character length tends to enforce the two-word password scheme I suggested earlier (TREE?FARMS, for example).

Windows NT also has the capability to remember the previous passwords a user provided. If you set this value to 1 or 2, the user will just cycle between passwords. He may even write them all down on a piece of paper. I normally find that you get better results at the five password level. At this point, most users consider it too much trouble to keep track of past passwords. Obviously, you can set this value as high as you want. The limiting factor is hard disk memory. As you increase the number of passwords, you'll also have to increase the storage they use. There is a point of diminishing returns that you should consider. I normally set the maximum at 25; no one is going to remember all 25 passwords he has provided.

The second section of the Account Policy dialog box deals with failed password entry attempts. Normally, Windows NT doesn't pay much attention to failed attempts. I always change this to the Account Lockout option, however. You'll definitely want to select this option if you provide any kind of external access to the workstation. Otherwise, a hacker could just keep trying passwords until he gets the right one.

Setting a level of five passwords is adequate in most cases. I can't think of any user who wouldn't get his password right after five attempts. The Reset Count After field is crucial to making this setting work right. It measures the amount of time between password entry attempts. If the amount of time between one failed attempt and the next attempt is longer than the count interval, Windows NT resets the count to 1. A hacker probably won't be willing to wait 30 minutes between access attempts.

The Lockout Duration group is pretty important if you provide external access to the workstation. I normally keep the account locked out until the administrator enables it again. There is a good reason to take this approach. The user might not realize that someone is trying to break into his account until he tries to use it and can't because the account is locked out. This little feature alerts both the user and the administrator to a potential problem with the account. Of course, this feature could also cause some additional work for the administrator if the user is one of those who chronically forgets his password. I normally use a duration of 30 minutes for workstations that lack an external connection. This way, Windows NT automatically enables the account after a specific amount of time passes. The user will get the idea that he should try to remember his password, and the administrator won't have to go through a lot of extra work.

The final section in this dialog box contains a single password. If you set the user's password to expire after a given amount of time, you might want to check the User Must Log On in Order to Change Password option as well. This forces the user to go to the administrator if he allows his password to expire without changing it. I normally keep it enabled for new users because it gives me an added opportunity to talk with them about security. After the user is added to the Power Users group, I uncheck the box, because he'll probably know not to let his password expire by then.

User Rights

Believe it or not, the User Rights Policy dialog box is one of the simplest yet most powerful security dialog boxes you'll find. You access it by choosing the Policies | User Rights command. Figure 23.12 shows what this dialog box looks like.

Figure 23.12. The User Rights Policy dialog box provides a lot more power than its diminutive appearance might suggest.

There are two fields in this dialog box: Right and Grant To. The Right drop-down listbox contains a plain English description of what the right does or how it affects the system. The right shown in the figure, for example, gives access to the workstation from a remote location. Notice that only the Administrator and Power Users groups can do that. Obviously, the Grant To field contains a list of people who can use this right.

OK, so what happens if you define a new local group or want to change the rights of an existing group? There are two buttons on the right side of the Grant To field. If you want to remove a right from a certain group, just select it from the Grant To list and click Remove.

Giving a group access to a specific right is pretty easy too. Just click the Add button and you'll see the Add Users and Groups dialog box shown in Figure 23.13. To add a new user or group, just highlight it in the Names listbox and click the Add button. The name appears in the Add Names listbox. After you click OK, those names appear in the Grant To listbox of the User Rights Policy dialog box.

Figure 23.13. This version of the Add Users and Groups dialog box allows you to grant rights to a specific user or group.

You should notice immediately that the Add Users and Groups dialog box doesn't contain any user names. Normally, you'll grant rights to a group instead of a user. This makes security maintenance a lot easier on the administrator. If you need to give a specific user a particular right, all you need to do is click the Show Users button. The user names will appear at the bottom of the Names listbox.

This dialog box also provides another important feature. You can highlight a group and display its members by clicking the Members button. Using this feature displays a dialog box like the one shown in Figure 23.14. All it contains is the name of the group at the top, followed by a list of its members. Notice that you can select a particular name from the list. Clicking Add will add that name to the Add Names listbox of the Add Users and Groups dialog box.

Figure 23.14. You can get a member list for any group by clicking the Members button.

The Add Users and Groups dialog box also contains a Search button, which allows you to look for a specific user or group. I described that feature as part of the "Adding New Groups" section earlier in this chapter, so I won't describe it again here. All you need to do to complete this action is click the OK button. User Manager will return you to the User Rights Policy dialog box and you'll see the names you selected in the Grant To listbox.

Audit

The last option on the Properties menu of User Administrator is Audit. It displays the dialog box shown in Figure 23.15. Audits can consume a lot of administrator time and effort if you let them. In fact, I normally turn all these features off unless I suspect some kind of network problem.

Figure 23.15. The Audit Policy dialog box allows you to monitor specific system events.

As you can see, this dialog box contains a list of specific system events, such as logon and logoff. You can choose whether you want to monitor successes, failures, or both. All these events are security related in one way or another. Some are pretty obvious. You can monitor how often users fail to log onto the network, for example, if you think that someone is trying to break in.

Some of the entries are a little more subtle. You might want to monitor network traffic by checking File and Object Access. A lot of failures might indicate some type of a security problem. Less obvious is the fact that you can use successful accesses to monitor how often a particular resource is used and by whom. Checking these items doesn't complete the task; you also have to set the file or object for monitoring. I'll show you how to do that in the following chapter.

So how do you actually view the results of this selection? Windows NT maintains a security log. You view it by using the Event Viewer. I showed you how to use this particular utility in Chapter 3, "Performance Primer." Look for the "Checking for Interactions with Event Viewer" section.

Using the Security Page of the File or Folder Properties Dialog Box


We're about to get into one of the most confusing and time-consuming areas of Windows NT to manage from a security perspective. Right-click on any folder or file, and you'll see a context menu. Choose the Properties option and select the Security page; you'll see something similar to the dialog box shown in Figure 23.16.

Figure 23.16. The Security page of the <File> or <Folder> Properties dialog box can enhance security or simply eat up administrator time.

As you can see, this dialog box contains three buttons: Permissions, Auditing, and Ownership. Each button displays a dialog box that controls specific aspects of directory or file security. We'll look at exactly how they work in a few moments.

Here's where this particular Windows NT feature can get time consuming. Think about the administrator who sets the security features for each file in a directory rather than taking a directory-wide approach to the issue. It happens all the time. An administrator will want to give one group access to file A and another group access to file B. Instead of putting the files in separate directories, the administrator will take the time to work with each file individually. Don't set yourself up for an administrative nightmare. Organize your files along application, usage, and security lines before you start to get into the configuration issues we'll cover in the next few sections.

Working with Permissions


Perhaps the most common event for a network administrator is assigning permission to use a directory or file to a specific group. Windows NT provides a fairly broad range of capabilities in this area. Clicking the Permissions button on the Security page displays the Directory (or File) Permissions dialog box shown in Figure 23.17. I chose to show the Directory Permissions dialog box because the File Permissions dialog box looks the same and offers a subset of the permissions you'll find here. As you can see, there are quite a few things you can do in this dialog box.

Figure 23.17. You can use the Directory (or File) Permissions dialog box to define who has access to a resource and at what level.

Setting Security Inheritance

Let's begin by looking at the two checkboxes at the top of the dialog box. Remember the administrator who created a lot of work for himself earlier in this section? If you organize your directories properly, Windows NT takes care of file security for you. As a default, Windows NT applies any changes you make to the files in the current directory. If you decide that you want to make the changes directory specific, disable the second checkbox. The first checkbox tells Windows NT that you also want to apply any changes in security to subdirectories. This allows you to make changes at one level in the directory hierarchy and let them flow down throughout the remainder of the directory tree.

Changing Group or User Access Levels

The next thing you'll want to look at is the Name listbox. You can place group or individual user names here. I always suggest that people use groups because they're easier to manage. Obviously, there are exceptions to every rule, so the capability to add individual users is important. Notice that there's a permission level to the right of every name in the list. You control this level with the Type of Access drop-down listbox below the Name listbox. Table 23.4 shows the types of access you can assign.

Table 23.4. Windows NT standard directory and file access levels.

Access Type Description
No Access This is the default setting for any group; it doesn't allow users to even see the directory or file.
List You can use this option to allow the user to see the directory, its file names, and any subdirectories. The user can also change to the directory (a requirement to view its contents). The user can't change any of the files or even open them.
Read I often use this level of access for directories containing executable files. It provides capabilities similar to the List option as far as the directory is concerned. The user also gains the capability to view and execute files. He can't change the file in any way.
Add If you occasionally conduct surveys or need the capability to store data in a way that the user can't change, you'll like this particular default access level. It allows the user to add a file to a directory. After he adds a file, however, he can't change it in any way. In fact, the user can't even access the file. This level of access is just like List, except for the capability to add new files.
Add & Read Some application programs store their INI files in the same directory as the program itself. That's where this particular level of access comes in handy. It combines the features of read access with add access. It allows the user to execute and view programs. He can even add new INI files if needed. This particular option restricts the user from making wholesale setup changes.
Change Windows NT uses this as the default level of access for everyone unless you change it. This level of access allows the user to do all the things I talked about for Add & Read. He can also change or delete data files or subdirectories. You can use this level of access for most data directories without problem.
Full Control Administrators and power users normally get full control of the directories on a local hard drive. This level includes everything the Change level provides. In addition, it allows a user to delete the directory and its files, assign directory permissions, and take ownership of the directory.
Special Directory Access There are times where none of the default setup options provides the level of directory access you need. You can select this option to change the default level of directory access to a special setup. I'll show you how to use this option in just a few moments. Suffice it to say for now that you'll want to consider carefully whether you really want to manually control security to a directory.
Special File Access Like the Special Directory Access option, this entry allows you to directly control the levels of access to a file. I'll show you how this works in a few moments.

Using the Special File or Directory Access Feature

What happens if none of the standard access level definitions will work in a specific situation? Suppose that you want to give a user every right provided by the Change level of access except the capability to delete directories. In that case, you'd start by selecting the Change level of access and then selecting the Special Directory Access level. You'll see the Special Directory Access dialog box shown in Figure 23.18. The Special File Access dialog box works the same way, so I'll discuss only the Special Directory Access dialog box for the sake of simplicity in this section.

Figure 23.18. You use the Special Directory (or File) Access dialog box to change individual security rights for a particular group.

Notice that you can choose between full access or a limited subset of all the access rights. Table 23.5 provides a complete description of all the access rights you can choose with Windows NT.

Table 23.5. Windows NT detailed access rights.

Right Description
Read (R) Allows the user the read the file or directory but not to change it.
Write (W) Allows the user to change the file or directory but not to read it. This right also allows the user to create new files or directories.
Execute (X) Allows the user to execute the file as long as it's an executable file. Note that even though this option is available for directories, you can't execute a directory. This option is made available so that you can control the file execute right at the directory level instead of flagging each file separately. You also have to have it to open the directory for viewing (Microsoft calls this changing to the directory).
Delete Allows the user to delete the file or directory.
Change Permissions (P) This is an administrator level right that allows the person to change the file or directory permissions.
Take Ownership (O) Allows the user to take ownership of the directory.

By now, you should have figured something else out. When you select a default level of access, you'll see some letters next to the level name. The first set of letters tells you what kind of directory access the level provides. The second set of letters tells you the same thing for file access. All you need to do is look up those letters in Table 23.5 to find out what they mean.

Adding/Removing Users or Groups

You'll need to perform two operations with the Directory (or File) Permission dialog box on a somewhat frequent basis even if you do set up security correctly: adding and removing users or groups. Removing a user or group is easy. Just highlight the entry you want to remove in the Name listbox and click the Remove button.

We've pretty much covered adding a user as well. All you need to do is click the Add button. You'll see the Add Users and Groups dialog box (refer to Figure 23.13). Take a look at the "User Rights" section of this chapter for more details on filling out this dialog box.

Auditing Events


At times, you may need to monitor access to a particular file or directory. Clicking the Auditing button in the Directory (or File) Properties dialog box displays the Directory Auditing dialog box shown in Figure 23.19. You have to use this dialog box with the Audit Policy dialog box (refer to Figure 23.15). I already talked about this second dialog box in the "Audit" section of the chapter.

Figure 23.19. You can use the Directory (or File) Auditing dialog box to monitor various access events.

If you look at the top of the Directory Auditing dialog box, you'll see the same two checkboxes I described for the Permissions dialog box. Look at the "Setting Security Inheritance" section of this chapter for details.

The Name listbox contains a list of users or groups you want to audit. We already covered the process of adding users and groups to this listbox in the "User Rights" section of the chapter. After you add a user or group to the listbox, you need to define what events you want to audit. The Events to Audit area contains two sets of checkboxes. Select a Success checkbox if you want to monitor the successful completion of a task by a particular group. Similarly, the Failure checkboxes monitor event failures. Refer to Table 23.5 for a complete list of the meanings of these entries.

Taking Ownership


You must own a file or directory before you can modify its permissions. Normally, the Administrator group owns all the files and directories on a drive. This group can give permission to other groups to take ownership, however. They can't transfer the ownership; only the other group can do that. So what does this mean to you from a security standpoint?

Every time someone changes the permissions for a particular file or directory, they leave a paper trail behind. You can view the ownership of a file or directory to see who changed security for it last. This trail improves overall system security by making it difficult for someone to damage the hard drive without leaving his signature on the job in one way or another.

Clicking the Ownership button on the Security page displays the Owner dialog box shown in Figure 23.20. Notice that it displays the current owner of the selected directory or file. One of the security-related tasks you should perform on a regular basis is checking this dialog box. If the ownership of a directory or file has changed, you know that someone has changed a permission and you need to find out what that change is.

Figure 23.20. The Owner dialog box tells you who currently owns a file or directory.

To take ownership of a directory or file, all you need to do is click the Take Ownership button. If this is a directory, you'll see a dialog box similar to the one in Figure 23.21. It allows you take ownership of all the files and subdirectories the directory contains without selecting them individually. Obviously, clicking Yes will save you a lot of time if you need to change the permissions of the files within the directory.

Figure 23.21. Windows NT allows you to take ownership of all the files and subdirectories in a directory with a push of a button.

System Security and the Administrator


Windows NT provides security capabilities that are far and away much better than those provided by Windows 95. You normally don't need to know the details in order to use them effectively. I've provided this section of the chapter for those of you who want to know more—what goes on beneath the user interface we've just explored. You don't have to read this section to use the security features Windows NT provides, but it doesn't hurt to know them.

There are more than a few books that will tell you Windows NT uses a token-based security scheme. I'm going to make life just a bit easier for you right now. Think of a token in the same way as an object for the moment, and you'll start out on the right foot in learning about the architectural details of Windows NT security. I've shown you that there are objects lurking beneath the surface of Windows several times in the book so far. Look at the architectural overview in Chapter 6, "An Architectural Overview," for example. Microsoft even refers to various Windows components, such as dialog boxes and icons, as objects in Windows NT.

Knowing that everything's an object makes security a bit easier to understand; at least it's a starting point. Objects are just a starting point, however. Users are the other part of the security equation. An object is accessed by a user, so security in Windows is a matter of comparing the object's protection to the user's rights. If the user has sufficient rights, he can use the object. The Windows documentation refers to an object's level of protection as a security descriptor. The rights a user has are called access tokens. Think of the security descriptor as a lock and the access token as a key. If the key fits the lock, you can open the object.

I'm going to be using a few programmer-related terms in this section, because there isn't any other good way to describe the details of security under Windows NT. The first term you're going to need to learn is structure. Think of a structure as a combination of a form and a pneumatic tube container (like the kind a lot of banks used to use when there were drive-up windows—some banks may still provide them). A program fills out the form (the contents of the structure), places it in one of those containers (the structure itself), and sends it to Windows via the pneumatic tube (a call to one of the API function calls). Just like a bank teller, Windows can send the container back to the application filled with whatever the application requested.

A security descriptor is the structure that tells the security system what rights a user needs in order to access the object. The user's access token is another structure that tells the security system what rights a user has in a given situation. Figure 23.22 shows both these structures.

Figure 23.22. Access tokens define the user's rights, whereas security descriptors define the protection level for a process.

Understanding Access Tokens


You'll find that there are two of ways of looking at a user's rights under Windows; both of them are related to objects in one form or another. The user's access token has a security identifier (SID) to identify user throughout the network; it's like having an account number. The user token the SID identifies tells what groups the user belongs to and what privileges the user has. Each group also has a SID, so the user's SID contains references to the various group SIDs he belongs to, not a complete set of group access rights. You would normally use the User Manager utility under Windows NT to change the contents of this access token.

So what is the privileges section of the access token all about? It begins with a count of the number of privileges the user has—not the groups he belongs to, but the number of special privilege entries in the access token. This section also contains a numbered list of privilege entries. Each privilege entry contains a locally unique identifier (LUID)—essentially, a pointer to an object—and an attribute mask. (Think of a pointer like you would a house address: It tells you the location of the object. If someone knows your address, he can find your house. The attribute mask is the list of rights I talked about in Table 23.5.) The attribute mask tells what rights the user has to the object. Group SID entries are essentially the same. They contain a privilege count and a numbered list of privilege entries.

Understanding Security Descriptors


Now let's look at the security descriptor. Figure 23.22 shows that each security descriptor contains five main sections. The first section is a list of flags. These flags tell you the descriptor revision number, format, and access control list (ACL) status. As a user, you wouldn't need to worry about any of these entries.

The next two sections contain SIDs. The owner SID tells who owns the object. I told you how to change the contents of this particular entry in the "Taking Ownership" section of the chapter. This doesn't have to be an individual user; Windows allows you to use a group SID here as well. The default owner in this SID is the Administrators group. If you use a group SID, it must appear in the access token of the person changing the entry. The group SID allows a group of people to own the object. Of the two SIDs, only the owner SID is important under Windows. The group SID is used as part of the Macintosh and POSIX security environment.

The final two sections contain ACLs. The security access control list (SACL) controls Windows' auditing feature. Every time a user or group accesses an object and the auditing feature for that object is turned on, Windows makes an entry in the audit log. I talked about this entry in the "Auditing Events" section of the chapter. The discretionary access control list (DACL) controls who can actually use the object. You can assign both groups and individual users to a specific object. We talked about group and user access in the "Adding/Removing Users or Groups" section of the chapter. I also talked to you about security levels in the "Changing Group or User Access Levels" and "Using the Special File or Directory Access Feature" sections of the chapter.



Note: There are actually two types of security descriptors: absolute and self relative. The absolute security descriptor contains an actual copy of each ACL within its structure. This is the type of security descriptor Windows NT uses for an object that requires special handling. The self-relative security descriptor only contains a pointer to the SACL and DACL on disk. This type of descriptor saves memory and reduces the time required to change the rights for a group of objects. Windows NT uses it when all the objects in a particular group require the same level of security. Windows converts a self-relative security descriptor to absolute format before it saves it to disk or transfers it to another process. So what does this mean to you as a user? The fact that you can click the Cancel button and reverse any of the security changes you've made is evidence of a self-relative ACL. If Windows didn't provide these two kinds of ACLs, every security change you made would become permanent the instant you made it.

An ACL consists of two types of entries. The first entry is a header that lists the number of access control entries (ACEs) the ACL contains. Windows uses this number as a method for determining when it has reached the end of the ACE list. The second entry is a numbered list of ACEs.

So what is an ACE? An ACE defines the object rights for a single user or group. Every ACE has a header that defines the type, size, and flags for the ACE. Next comes an access mask that defines the rights a user or group has to the object. Finally, there's an entry for the user's or group's SID.

There are four types of ACE headers (three of which are used in the current version of Windows). The Access Allowed type appears in the DACL and grants rights to a user. Windows uses it to add to the rights a user already has to an object on an instance-by-instance basis. Suppose that you want to keep the user from changing the system time so that you can keep all the machines on the network synchronized. There might be one situation, though, such as daylight savings time, when the user needs this right. Windows would use an Access Allowed ACE to give the user the right to change the time in this one instance. An Access Denied ACE revokes rights the user has to an object. Windows uses it to deny access to an object during special system events. You could deny access rights to a remote terminal while you perform some type of update on it, for example. The System Audit ACE type works with the SACL. It defines which events to audit for a particular user or group. The currently unused ACE type is a System Alarm ACE. It will allow the SACL or DACL to set an alarm when specific events happen. Suppose that a user tries to access a file even though he isn't supposed to. A System Alarm ACE could send a message to the network administrator and let him know about the security breach immediately.

On Your Own


Take this opportunity to design your own security plan. Work with the network users and management to come up with a plan that is both fair and reasonably secure.

Analyze the plan you created for leaks and potential security risks. Make sure that you tell management about these risks and their effect on the network. Also come up with contingency plans to plug the leaks if management decides that the risk is too great.

Spend some time training the users on your network about security. It's very important that you also take the time to explain what types of passwords are acceptable. Spend a little time with each user who has problems understanding the security plan.

If you're a home user, try setting up a variety of security options on your own machine. You might want to create a security profile for young users, however, that allows them access to programs they can use but removes access to programs that could damage your machine. Try using the User Manager and other tools I described here to make the process of creating a home security plan easy.

Try using the auditing features Windows NT provides for a few weeks to see how they affect system performance and how many resources they use. It's important to know what to expect in the way of output and what you'll need to provide to make these auditing features work. You won't have time to work out these details when a hacker is busy trying to access your workstation.

Previous Page Page Top TOC Next Page